专利摘要:
The invention relates to a new method for securing digital data during storage or archiving, the method consisting in: - creating, from a source file FO of digital data, a set of data blocks independent and identifiable grouped in an FB block file (15); assign (17) to each of the blocks one or more storage site (s) (17, 18, 19), then transfer (20,21) the blocks to the dedicated sites, and establish a TC Chart Table (22) linking each block reference code to the numbers and addresses of the dedicated sites; - select the operational parameters and the application of two related complementary options, one to the block fingerprint calculation (16, 25) and the other to the data encryption, thus making it possible to modulate the level of security sought based on the nature of the data.
公开号:FR3037174A1
申请号:FR1501179
申请日:2015-06-08
公开日:2016-12-09
发明作者:Jean Marc Marie Joseph Rietsch
申请人:Jean Marc Marie Joseph Rietsch;
IPC主号:
专利说明:

[0001] The present invention relates to the field of securing digital data during storage or archiving thereof. The invention relates more particularly to a method making it possible, on the one hand, to increase the security of the storage and archiving of digital data of any provenance and, on the other hand, because of the very design of said method, to modulate the level of security that can be selected according to the nature and use of said digital data. Beside the known data encryption devices, there are now several logic of 1.5 secure storage of digital data data among which we can mention: - RAID technologies (Redundant Array of Independant Disks) which consists in storing a file, cut into pieces, on different disks following several levels of cutting and security. Thus, different types of RAID storage are known and they are distinguished in particular by the redundancy systems used; the method of storing the information, called CAS, (Content Addresses Storage) which allows access to data stored in a storage space by using an identification key whose conservation is necessary to find the retained data. At the same time, in the telecommunications sector, there is a well-known logic of packet transmission which consists of cutting a data file to be transmitted into a plurality of completely independent data packets and reconstructing the entire file when all the packets have arrived. to destination. For example, the public network TRANSPAC operating since 1978. However, the assembly of the various concepts of the prior art has never been implemented. Moreover, the methods of the prior art require a great deal of computing resources and require complex organization (s). Moreover, they do not offer the possibility of adapting the level of security to the nature of the data to be protected. SUMMARY OF THE INVENTION We propose here a device for exploding a digital data file into different elements which can then be stored each on separate spaces, preferably at different physical locations and geographically distant. This storage mode 3037174 3 is based on the current logic of the "cloud". We do not really know where the information is stored but we can interrogate and find them without problem. Be that as it may, in the cloud, the information is stored together in a specific place so that their confidentiality is absolutely not assured. The device proposed here ensures a high confidentiality of the data insofar as their direct access to the storage bays where they are kept will never allow the completeness of the data because they will have been cut beforehand into fragments or blocks. Furthermore, this technique applies regardless of the storage device used which may or may not further strengthen the security of the data.
[0002] Only those who have access rights will be able to repatriate all the fragments in a coherent way. A first object of the invention is to associate in a new combination several techniques, partly known per se, in order to improve the overall security of storage or archiving of digital data whose binary elements are grouped together in a original file, in particular by making it possible to improve each of the security criteria such as the availability, the integrity, the confidentiality and the traceability of said data.
[0003] In this context, a first aspect of the invention relates to the identification, authentication of the initiator (physical or physical person) of a request to the management center of the method of the invention relating to the storage or the archiving of an initial FO file of digital data, under conditions ensuring the guarantee of their origin and their integrity, from the Management Center. A second aspect of the invention relates to the processing of said initial digital data file FO for the purpose of restructuring it into a number of independent and identifiable blocks grouped in the FB block file. A third aspect of the present invention relates to the implementation of the distribution of identified and formatted blocks within a plurality of third-party storage or archiving sites, a site that can store multiple blocks and a block that can be present in several sites. It will be appreciated that the functional modes and operational parameters of the method of the invention are assigned to each block and are indicated in the specific fields constituting the format of said block.
[0004] After reading each block, a Transmitter / Receiver device transmits the data blocks to their dedicated storage sites and, in parallel, the Central Processing Unit (CPU) constructs a table known as the "Map Table" essentially allowing to associate the unique identification code of a block and the number and the addresses of the respective storage sites of said block. The importance of this map table is great insofar as it does not contain any reference to the binary elements of the data allocated to each block but where it alone can recover all the complete blocks distributed in a plurality of sites, This will be a prerequisite for rebuilding the original F0 file.
[0005] Accordingly, the method of the invention must implement any known means suitable for securing this Chart Table. In the continuation of the objective of enhancing the security of digital data, a fourth aspect of the invention relates to the optional encryption of the data assigned to the different blocks using the application of various encryption modes using algorithms and keys, these modes may vary from one block to another.
[0006] The knowledge of said modes will obviously be necessary at the time of decryption of the data. However, for security purposes, the algorithms and keys used will not be integrated within any field of the block format but, on the other hand, they will be stored in the corresponding Chart Table whose characteristics have already been mentioned. Still in the same objective, a fifth aspect of the invention relates to the calculation of the footprint of each block, the result of which will also be stored in the Chart Table and may thus make it possible to verify the integrity of the data attributed to each block during of their return from the dedicated sites in order to reconstitute the original file F0.
[0007] A second object of the invention is to make it possible to select the optimal NS Security Level that one wishes to implement depending on the nature of the data, their importance in the various fields they concern, or , their confidentiality and their durability. A sixth aspect of the invention describes the means that lead to a possible selection of the NS Security Level. Among these means, the essential element is in the form of a Decision Table which defines, for different levels of security, from the lowest to the highest, the functional modes and the values of the operational parameters permitting achieve each of the Security Levels in the Decision Table. Said Security Level I S is selected when inputting the original file FO and the Decision Table is interpreted and executed by the CPU of the Management Center until obtaining the corresponding Chart Table 10. A seventh aspect of the invention relates to the reconstitution of the initial FO file with the help of secure and secure map tables, which do not contain any of the data to be protected but provide the information necessary for such reconstitution. BRIEF DESCRIPTION OF THE DRAWINGS The invention will be better understood from the following detailed description and the accompanying figures in which: Figure 1 shows a block diagram of the first phase of the process of the invention. Figure 2 shows a block diagram of the second phase of the method of the invention supplemented by the optional footprint calculation of each block. Figure 3 shows a block diagram of the third phase of the method of the invention. FIG. 4 is a block diagram of the implementation of the optional process of encrypting the data assigned to each block. FIG. 5 represents a block diagram of the method of the invention implementing the selection of the 1.0 Security Level. FIGS. 6a, 6b, 6c and 6d show partial functional diagrams of the process of reconstitution of the initial file F0. Description of Some Embodiments In the following we will use indifferently the terms store and archive, or storage and archiving. Figure 1 shows the block diagram of the first aspect of the present invention. A request R is sent by an Applicant to the Management Center (G) responsible for the storage or archiving of digital data and, more particularly, to ensure the security of said data appearing in the form of a file. of origin FO recorded on any support. The Management Center (G) 1 has appropriate means 5 - to identify and authenticate the Applicant, and to provide proof of the existence of said data at the date of the request; - To provide the guarantee of the origin and the integrity of the data file that the Management Center 1 commits 10 to store or archive ensuring their integrity, confidentiality and durability. To do this, a client database 3 associated with a clock 4 makes it possible to achieve the aforementioned first objective, but, for the other guarantees, the Central Processing Unit (CPU) 2, associated with the calculation means footprint 6 of the FO file are necessary, thus leading to an electronic signature 7, in the case where the signer is a natural person, or to an electronic seal 7 if the signatory is a legal person or zo a machine. One can also, for example, calculate said fingerprint and send it to an electronic time stamp service that associates with that fingerprint a serial number, a date and a time and seals the whole.
[0008] A preferred embodiment of the present invention further contemplates making electronic signatures based on an asymmetric encryption algorithm based on the use of a two-key. The principle consists, after the calculation of the fingerprint of the file, to encrypt the latter with the private key which only the signer has control. All these precautions having been taken, the digital data of the original FO file and the fingerprint E (F0) FO file are transferred into the memory system 5 5 Management Center 1. The second aspect of the The present invention is illustrated by the representation of the block diagram of FIG. 2 relating to an embodiment of the second phase of the method of the invention and intended to restructure the original FO 8 file in the form of a plurality of blocks of independent and identifiable data. The term "block" denotes a sequence of bits taken, in their initial order, from the digital data of the FO file 8 and being in a format of several fields among which a first field reserved for the unique identification code. CI 9 of said block consisting of a label F0 * specific to the FO file and the Order Number NO permanently assigned to said block during its formation 3037174 11 - a second field, called Data Field 10, grouping the elements binary data assigned to said block; - several other fields for operational indicators whose respective contents will evolve during the process, as will be described later. The blocks are constructed in such a way that the set of binary elements, in their original order, of the data of the original FO file satisfies a one-to-one identity relation with the set of binary elements of the data contained in the totality. blocks considered successively according to their Order Number NO. For the formation of a block, the associated CPU 2, at a counter 11, executing the instructions of a first programming law takes 12, from the FO file 8, a number "1" of bits. "Eb" in their initial order to fill the "Data" field 10 of the block in formation and it simultaneously assigns to it, in the dedicated field, the unique identification code CI 9 consisting of the specific label F0 * of the FO file and Order Number NO indicator of the position of li b bits taken from FO file 8 and allocated to said block "i".
[0009] The number "1" represents the size of the block.
[0010] Said first programming law associated with the formation of the blocks 13 defines the first operational parameter that constitutes the total number of blocks "k", knowing that the confidentiality of the data will be all the better than the number of blocks "k". will be big. Said first law also determines a second operational parameter by imposing that the size "1" of the blocks is constant for all the blocks (to the nearest unit) or is variable from one block to the other, rendering 10 blocks of variable size contributing, as the increase in the number "k", to the improvement of data confidentiality. According to one embodiment, the processor of the CPU 2 executing the instructions of the first programming law can use a counting procedure of the bits, block by block, such that the size of the blocks is constant and, for example, equal to EB / k = 1, where EB represents the total number of bits "eb" contained in the file FO 8, calculated automatically, for example, during the input of said FO file 8 after examination of the initial request Rq . All blocks will then appear in the block size field 14, indicating the size of the block, a value 1 ". The last block may possibly be incomplete depending on the value of the EB / k ratio and the size of this block will be less than "1". According to another option, the procedure for counting the bits "eb" assigned to each of the "k" blocks 5 can be random and the indicators 1, intervening in the respective Block Size 14 fields will, accordingly, be variable. If block management issues occur related to the physical size of the entire block, padding characters can be used to make their size equal. The blocks thus formed and formatted are stored one after the other in an FB block file which can be stored in the system memory 5 or, preferably, in a faster access 5 'auxiliary cache. said FB block file being, in a preferred embodiment, consisting of a simple queue, for example of the FIFO type. FIG. 2 shows in its left-hand part (without calculation of the blocks' fingerprints), the contents of the blocks 9, 10, 14 of the FB block file 15 at this stage of the process, illustrating the identification code 9 (label of the FO file * and Order NO number of the block), the block size indicator 1, and the eb bits, assigned to this block.
[0011] In a preferred embodiment, illustrated on the right-hand part of FIG. 2 (with block imprint calculation), an additional processing of the blocks intended, in particular to ensure, at all times, the integrity of the blocks. of the 5 binary elements "eb" assigned to each block, consists in calculating the footprint of each block as soon as it is formed by conventional computing means 6 having several possible algorithms stored at 6 ', and preferably using two algorithms different impressions. The results El of the block fingerprints are grouped together in a first table, called the "fingerprint table" TE 16 consisting essentially of two columns making it possible to associate with each block identification code C1 the value of corresponding fingerprint E, associated with its calculation algorithm aei. The said TE 16 impression table is arranged in such a way that it can be easily combined with other tables, as will be described later. It is also possible to plan to directly record the information from the Fingerprint Table in the Final Mapping Table. This possibility also exists for the other modes studied below. As soon as the block file FB 15 is complete and stored in memory 5 or 5 ', the method activates the instructions of the second programming law implemented according to FIG. 3. FIG. 3 represents a block diagram of a Embodiment 5 of the third aspect of the invention. This step consists in implementing a second programming law whose execution by the CPU of the CPU 2 comprises the following steps: assigning 17 to each of the different blocks of the file 10 of blocks FB 15 one or more address (es) available third-party site (s) registered at 18 for storage or archiving, third-party sites that may be local, relocated, or still be the result of the current "cloud" logic; in parallel, indicate in the appropriate "Site" field 19 of the format of each block, the number ji and the respective sik addresses of the dedicated sites. The set of blocks thus formatted constitutes the new FBS block file 23 kept, for example, in memory 5 '; and then transmit, by means of conventional and appropriate communication means 20, each block to the dedicated storage site (s). According to a preferred embodiment, the CPU of the CPU 2 extracts the blocks of the FB file 15, block by block, and from a list of available storage site addresses 18, it assigns, randomly or parameterized, one or more site (s) to each of the blocks. by writing the number j, and the corresponding sik addresses (es) in the "Site" field 19 of the block format reserved for this purpose, then it transfers the block to the transmitter / receiver device E / R 20 which, after reading the addresses, transmits the block to the dedicated storage site (s) 21. The multiplicity of said storage sites increases the complexity of the grouping of the blocks thus disseminated and, consequently, reinforces the confidentiality of the data.
[0012] However, for management reasons, it is possible to moderate the randomness of the allocation of said sites by fixing, beforehand, a maximum number of sites for a given block and / or for all the blocks. FIG. 3 also shows that, simultaneously with the assignment of the sites, the CPU of the CPU 2 constructs a table that we will designate as the TC Chart Table 22. The latter consists of two columns, the first column records successively the identification codes CIi of all the blocks and the second column indicates the number ji and the addresses of siil, sii2, ---, siii storage sites assigned to each block identified in said first column. Other embodiments are possible for those skilled in the art. For example, it is possible to establish, from the FBS 23 block file previously registered in the cache 5 ', which groups all the blocks after assignment of the third sites, a plurality of queues 24. , one per dedicated site, also stored in the auxiliary cache 5 ', and each containing a set of blocks for the same dedicated site, which allows their transfer to the respective sites in a single transmission operation . After each transmission, the Transmitter / Receiver 20 of the Management Center 1 receives the acknowledgment of receipt from the different sites. If a possible incident occurs, a new issue of the block (s) in question is performed, as is the case conventionally. However, this procedure also justifies keeping the FBS file 23 in memory 5, while being able to be erased later. Said map table TC 22 is of great interest insofar as it contains no trace of the bits allocated to each block but where it alone makes it possible to recover all the complete blocks distributed in a plurality of storage sites, this which is a prerequisite for any subsequent reconstitution of the original FO 8 file. The TC 22 map table must therefore be secured by conventional means, for example, by being stored in memory 5 and saved on the site of the Center. Management 1, but it can also be kept on one or more remote third-party sites, provided that it is encrypted in order to respect the confidentiality sought. In the context of the preferred embodiment which implements the application of the footprint calculation 6 of each block and which leads to the establishment of the fingerprint table TE 16, the latter 16 will be combined with the first type of TC 22 map table to arrive at a second type of TCE Final Map Table 25 now consisting of three columns and associating with each block identified by its CIi code, both said result of the corresponding fingerprint calculation and the number ji and addresses 15 storage sites dedicated to said block. The TCE Chart Table 25, like the Chart Table TC 22 requires, for the same reasons already mentioned, to be secured using the same means previously mentioned.
[0013] After the last acknowledgment from the last site to which the last block was transmitted, the TC Chart Table or the TCE Table thus completed is stored in the system memory 5. This may trigger the deletion of the intermediate FB files. And FBS 23 and that of the original file FO 8 and, optionally, that of their respective copies. In fact, the TC Chart Table or the TCE Table associated with the content of all the fields of each block 5 stored or archived in the various third party sites, provide all the information necessary to reconstitute, at the desired moment, the original file FO 8 , which encourages, as has already been suggested, to secure TC Tables and TCE, only able to repatriate blocks distributed between the 10 third sites. Figure 4 shows a block diagram of another preferred embodiment implementing an optional procedure for enhancing the securing of data and, in particular, their confidentiality by involving the encryption of said data. As indicated in FIG. 4, the application of the encryption process carried out at 26 occurs, for reasons of security, as soon as possible after the formation of a block. Thus, for example, as soon as the i'th block is formed, that is to say that its identification code CI; is determined as well as its size li and the ebi bits that are assigned to it, the processor of the CPU 2 selects, essentially randomly among several modes (algorithms and keys) of encryption (symbolized by "mcht") 28, a mode mcht; for example, for said first block "i".
[0014] It is important to note that, from the mcht "encryption mode selected at 28, the information necessary for the decryption of said data is also derived. Consequently, for security reasons, it is essential not to integrate the applied mode "mcht" within the blocks before they are transferred to a plurality of dedicated storage sites. After application of said mode "mcht", the initial data "eb" is replaced by the encrypted data "eb" and the block corresponding to these encrypted data 15 joins the new encrypted block file FB * 29 which is stored in the cache memory 5 . As soon as an "mcht" encryption mode is assigned to a block, simultaneously, the CPU of the CPU 2 establishes a table, called "encryption table" Tcht 30 having two columns, the first column listing the codes CI identification of the blocks and the second column associating with each identification code Cli the encryption mode mcht; used for this block. By combining the cipher table Cht 30 with the first type of map table TC 22 obtained after block distribution in their respective storage sites, a third type of three-column final map table TCH 31 is established, linking d-codes. CI identification, "mcht" encryption modes, 5 "j" numbers, and "if" addresses of dedicated storage sites. Similarly, if the calculation option for E-block fingerprint is also applied, the fourth type of TCHE Final Map Table 32, taking into account the TE 16 Fingerprint Table, will consist of four columns linking identification codes. CI, "mcht" encryption modes, E imprints, "j" numbers, and "if" addresses of dedicated storage sites. For identical reasons, the TCH and TCHE Tables are secured, as previously mentioned. Figure 5 is a block diagram of the means used in the foregoing aspects of the present invention for use in meeting the requirements of a pre-selected NS security level. Depending on the nature, confidentiality, criticality or other data to be stored or archived, the desired Security Level may vary and an optimal Security Level is often sought in relation to the actual need for security, but also with respect to the processing time, the cost and the complexity of the security means involved. The central element making it possible to modulate the Security Level consists in establishing beforehand a TD Decision Table 33 defining the functional modes and the operational parameter values corresponding to the different NS Selectable Security Levels, notably when entering the request Rq. ao of protection of the original FO file 8. According to a preferred embodiment, the functional modes and operational parameters selected by the TD Decision Table 33 as a function of a determined Security Level NS relate to 15 - the number of blocks k, knowing that the higher k is, the smaller the size e of the blocks will tend to decrease and the better will be the confidentiality, - the number of storage sites allowing also to improve the confidentiality if the number of sites increases, 20 - the number of copies, that is to say the number of sites storing a same block, said copies being able to intervene in case of defects observed on the integrity of the blocks, - the execution / Yes of the calculation of fingerprints E for each block allowing, if the choice is positive, better to ensure the integrity of the blocks during the reconstitution of the file original F0, - the execution Yes / No data encryption allowing, if the choice is positive, to strengthen the confidentiality of these data. A Look-up Table 35 groups together all available functional modes and operational parameters, the multiple combinations of which are capable of determining the different NS Security Levels. The TD Decision Table 33 is implemented by the processor of the CPU 2 after selection of the NS Security Level.
[0015] Once the Security Level NS is determined, the functional modes and operational parameters corresponding to the choice of the TD Decision Table 33 are recorded, for example, in an auxiliary cache 34 reserved for said parameters for control purposes. 20 cases of possible subsequent malfunction. The CPU 2 then implements all the previously described processes separately to highlight the different basic steps of the method of the invention including the different options that may be taken into account by the Decision Table 33.
[0016] The final map tables, regardless of their types, TC, TCE, TCH, TCHE are, as already described above, transferred to the system memory 5 and secured in an appropriate manner. It is also possible to use only one map table updated directly as the blocks are formed. After the return of the write acknowledgment of the last block from the last dedicated storage site and after the implementation of the securing of said final map tables, in particular after they have been recorded in the system memory 5, it is possible to consider removing the original file FO 8, provided to store in memory 5 its footprint E (F0) 15 calculated when entering the request Rq, according to an algorithm determined by the Management Center 1. Figures 6a 6b, 6e and 6d represent several functional diagrams and flow chart relating to the fourth phase of the method of the invention, the implementation of which results from a request concerning the reconstitution of the original FO file 8. To do this, a first step, performed by the CPU 2 (FIG. 6a), is to transmit an "S" signal to all the dedicated storage sites whose addresses are read in the map table. that final (TC, TCE, TCH, TCHE) 22, 25, 31, 32 stored in memory 5 and by any suitable means of transmission. The signal "S" is designed to indicate that the blocks to be extracted relate only to those which contain in their "Identification" (CI) field the specific flag F0 * of the original file F0. In a second step (FIG. 6b), the reception system 20 collects all the blocks that reach it 10 from the different sites 21 in a block file FR 36. The CPU 2 then implements, on the blocks of the file FR 36 a sorting procedure according to a conventional algorithm whose sorting key is the Order Number NO of the block, knowing that at an Order Number NO only corresponds to one block and that this Number appears in the Code CI identification of the block, to lead to the establishment of two files FR1, 38 and FR2, 39. The first file FR1 38 contains a set of blocks, which differ from each other by at least 20 their order number NO, the second file FR2 39 grouping all blocks that have been stored in several dedicated sites and are at least as duplicates. At this stage of the process, a first check of its correct progress consists in observing that the number of blocks of the file FR1 38 is equal to the number "k" of blocks of the original file F0. In addition, a test relating to the integrity of the data assigned to each block can be performed from the FR1 file 38. Thus, FIG. 6c shows the functional flow chart associated with said integrity test. For all the blocks of the file FR1 38, the process is as follows: in block "i", the total number of ebi bits in the "Data" field is counted and is compared with the value li inscribed in the " Block size. In case of equality, the process continues for the next block i + 1, otherwise, in case of inequality, it is possible to search if the block "i" appears in the file FR2 39 and the similar cycle of the test is resumed.
[0017] This demonstrates another benefit of storing a given block in more than one dedicated site in order to ensure the integrity of the data that has been assigned to it. Another integrity test is possible if block fingerprinting is a selected option. Thus, from the file FR1 38, for each block "i", a footprint calculation Ei 'is undertaken, using the same algorithm aei indicated in the final map table TCE 25 or TCHE 32 stored in memory 5, which also gives the corresponding print result Ei 3037174 27 to the same block "i" that was present in the original file F0. The comparison between the fingerprints Ei 'and Ei makes it possible to verify the integrity of the data after storage. s Figure 6d represents the final step of restoring the original file. According to one embodiment, the CPU 2 takes at 40 the bits present in the "Data" field of each block of the file FR1, 38 and transfers them to a queue 41 10 according to the same consideration of the numbers. NO order that during the sampling performed at 12 during the second phase of the process of the invention (Figure 2). A typical concatenation operation 42 for the bit records of the queue 41 results in the final file FObi, 43 which should be identical to the original file F0. To verify this assertion, it suffices to compare at 45 the fingerprint E (F0) of the original file FO calculated by the Management Center 1 and stored in memory 5, with the print E (FObis) of the reconstituted file FObi. , calculated in 44 by the Management Center 1 according to the same calculation algorithm. When selecting options to better ensure the integrity and confidentiality of the data to be stored through Decision Table 25 33 or not, the Final Map Tables TC 22, TCE 25, TCH 3037174 28 31 and TCHE 32 play a decisive role in the process of reconstituting the original F0 file. Indeed, they provide the essential information necessary for the reconstitution, insofar as, not only do they make it possible to locate the storage sites of the different data groups, but also to establish the relationships between the CI identification code, E-stamp value and algorithm used "ae", and / or so-between CI Identification Code and mcht encryption mode "whose knowledge is fundamental for subsequent decryption. It will also be noted that all the latter information essential for the reconstruction of the original file F0 does not appear in the blocks. Consequently, it is important to emphasize that the said final map tables TC 22, TCE 25, TCH 31 and TCHE 32 are stored in the memory 5 of the Management Center 1 and, furthermore, saved and secured by all means as has already been mentioned. Various modifications can be made to what has been described herein in the embodiments and their implementation of the method of the invention without departing from the scope of the invention.
权利要求:
Claims (8)
[0001]
REVENDICATIONS1. A method of improving the security of digital data for storage or archiving, temporary or permanent, characterized in that it comprises a new combination of three distinct phases the first phase of a) identify and authenticate the request (Rq) a user wishing to protect his own digital data presented as an initial file (F0) [8]; b) calculating in [6] the fingerprint E (F0) of the file (F0) [8] according to appropriate algorithms in order to constitute a proof of the existence of said data at the date of said request (Rq), for example, using an electronic time stamp, as well as guaranteeing the origin and the integrity of said data by relying on an electronic signature [7] or an electronic stamp [7]; c) transferring said digital data and the fingerprint E (F0) of said initial file (F0) [8] into a memory of the system [5] and ensuring the implementation under control of the Management Center (G) [1] said method, and d) enter, if necessary, the operational parameters required for the operation of said method; the second phase consisting in 3037174 e) applying to the Central Processing Unit (CPU) [2] a first programming law making it possible to restructure the original file (F0) [8] in the form of a plurality of blocks independent and identifiable [13] whose number "k" and size "1", constant or variable, are determined in said first law, the concatenation of said blocks to allow later to reconstitute said original file (F0) [8 ], said blocks being structured according to a format presenting a "Data" field [10] for the "eb" bits of the respective data assigned specifically to each of said blocks and several fields reserved for information each indicating a useful characteristic relating to the said block, such as the unique identification code, abbreviated under the acronym (CI) [9], of the block or its size "1" [14], all the blocks thus formed and formatted constituting the block file (FB) [15], which is stored in memory [5, 5 ']; And the third step of f) having the CPU [2] apply a second programming law for transferring [17, 20] blocks of the block file (FB) [15] to a plurality of storage sites. [21], each block corresponding to at least one storage site, the storage sites can be local, remote or processed in "cloud" mode and can also use, in-house, all the conventional means of securing; g) insert in [17] in the format of each block an additional field [19] intended to contain the number and the addresses of the respective third sites to which said block is to be transferred, all the blocks thus formatted being grouped together in the file (FBS) [23]; h) then transfer to [20], by any appropriate transmission means 10 [21], either block by block or by site, all the blocks of said block file (FBS) [23, 24] to the respective sites dedicated; i) then, from said block file (FBS) [23], establishes a first type of Final Map Table (TC) [22] in the form of a two-column table, the first register Identification (CI) of the blocks and the second associating with each said Identification Code (CI) the number and address (addresses) of the dedicated storage site (s); and j) transfer the resulting Final Map Table (TC) [22] to the system memory [5] and secure it appropriately.
[0002]
2. The method according to claim 1, further characterized by encrypting [26] the digital data 3037174 32 contained in the blocks of the block file (FB) [15] according to "mcht" encryption modes ( algorithms and keys) [28] appropriate and can vary from one block to another and thus transform the file (FB) [15] into a file (FBK) s [29] containing the encrypted data. For security purposes, an Encryption Table (Tcht) [30] is established to ensure the correspondence between a block determined by its unique identification code (CI) and the encryption modes "mcht" implemented to encrypt the data of said block. Said Cipher Table (CCT) [30] is intended to be combined with said Chart Table (TC) [22] to establish the second type of Final Chart Table (TCH) [31] indicating, for each block, the unique match. between identification code (CI), number "j" and addresses of third-party storage sites "if" and encryption mode "mcht". Rather than working on several map tables and then combining them, it is also possible to work directly on the final map table.
[0003]
3. A method according to claim 1 or claim 2, further characterized in that it makes it possible to calculate [6] according to several possible algorithms "ae" the imprint E 3037174 33 of each block formed and formatted in accordance with FIG. step e) [13] and at the same time constructing an Fingerprint Table (TE) [16] establishing the unique link between the Block Identification Code (CI) and the footprint (E) of said block associated with the algorithm 5 " used. The said Fingerprint Table (TE) [16] is then combined with - the Chart Table (TC) [22] to form the third type of Final Map Table (TCE) [25], with three columns uniquely connecting for each block, identification code (CI), number and addresses of the third storage sites (j, si) and footprint plus algorithm (E, ae), or the encrypted Map Table (CCT) [30] to form the fourth type of Final Four-Column Final Map Table (TCHE) [32] connecting uniquely for each block, Identification Code (IC), number and address of third-party storage sites (j, si), footprint plus algorithm (E, ae), and encryption mode (mcht). Whatever the resulting final map table (TC, TCE, TCH, TCHE) [22, 25, 31, 32], it is transferred into the system memory [5] and secured appropriately. Rather than working on several map tables and then combining them, it is also possible to work directly on the final map table.
[0004]
4. The method according to claims 1, 2 and 3, further characterized in that it allows a modulation of the Security Level (NS) appropriate for the storage or archiving of a set of digital data grouped in an original file (F0) [8]. A Decision Table (TD) [33] defines the combinations of the functional modes and the operational parameters which lead to different determined Security Levels (NS), said Security Level (NS) being selectable when entering the file. origin (F0) [8]. Functional modes and operational parameters defining a Security Level (NS) refer to - the number of blocks "k"; - at the size "1" of the blocks (Fixed / Variable); - the total number of dedicated sites "j"; The number of copies, that is to say the number of different sites storing the same block; - the execution (Yes / No) of the calculation [6] of fingerprints (E); - Execution (Yes / No) of the data encryption process. 3037174 35 After selecting a given Security Level (NS), the CPU of the CPU [2] takes into account the functional modes and the operational parameters defined in the Decision Table (TD) [33] corresponding to the s Safety (NS) selected and transfers them to an additional auxiliary cache [34] connected to the CPU [2] and reserved for the modes and parameters used to obtain said Security Level, then the CPU [2] executes the associated respective instructions at said selection, as already described. The different Final Map Tables (TC, TCE, TCH, TCHE) [22, 25, 31, 32] are transferred to the system memory [5] and secured appropriately.
[0005]
5. Method according to claim 1, further characterized in that it comprises a fourth phase relating to the reconstitution, on request, of the original file (F0) comprising the following steps k) transmit, from the center of Management [1], to all the dedicated storage sites and listed in the Chart Table (TC) stored in the system memory [5], an extraction signal (S) out of the storage means present in said dedicated sites, all the blocks identified by the flag (FOE ') specific to the original file (F0) [8]; 1) receive all the identified blocks thus transmitted by the dedicated storage sites in a block file (FR) [36] stored in the cache [51; m) from the file (FR), create a first file (FR1) s [38] in which all identified blocks, appearing once and only one, and a second file (FR2) [39] in which do not appear that blocks stored in more than one dedicated third party site; n) for data integrity verification purposes, compare, in the file (FR1) [38], and for each block CIi, the number of bits ebi with the value li indicated in the field "size corresponding block; o) retrieves the ebi bits from all the blocks of the file (FR1) [38] in the order of the Order Numbers (NO) in the initial formation of the blocks [13] and apply to them a conventional operation of concatenation in [42] to reconstruct the file (FObis) [43]; p) in order to check the integrity of the files (F0) [8] and (FObis) [43], compare the fingerprint E (F0) of the original file (F0) kept with its calculation algorithm "ae" , in the memory [5] of the Management Center [1] with the new fingerprint E (FObis) [44] calculated according to the same algorithm "ae". 3037174 37
[0006]
The method according to claims 2 and 5, further characterized in that the encryption option having been selected to enhance the confidentiality of the stored data, the implementation of steps k) and 1) leads, from the same way, to the said file (FR) [36], but this then contains a set of blocks in which the data are encrypted. At this stage of the process, their decryption takes place using the Final Map Table (TCH) [31] 10 stored in the memory [5] and providing, under these conditions, the essential information relating to the encryption mode " mcht "corresponding to each block (CI). The other steps from m) to p) remain functionally unchanged. 15
[0007]
7. The method according to claims 3 and 5, further characterized in that the option of calculating the fingerprint of each block has been selected to reinforce the integrity of the data, the implementation of steps k) and 1 ) leads, in the same way, to said file (FR) [36] from which the footprint Ei 'of each block is computed with the same algorithm ae, stored in the final Mapping Table (TCE) [25]. ] for each CI block ,. It suffices to compare the fingerprints Ei 'and E, to confirm, 3037174 38 in case of equality, the quality of integrity of the data after storage.
[0008]
8. The method according to claims 4, 5, 6 and 7, further characterized in that the implementation of the Decision Table (TD) [33] can lead, in order to guarantee maximum data security, to the simultaneous selection of the options for the encryption of this data and the calculation of the block fingerprint. Under these conditions, the steps k) and 1) lead, in the same way, to said file (FR) [36] whose blocks will undergo the decryption process and the comparison test of the block fingerprint values. To do this, the Chart Table (TCHE) [32], kept in the memory [5], will provide the necessary information insofar as it associates respectively the identification code (CI) of the block, the encryption mode mcht ", The imprint value and its calculation mode (E, ae). The other steps from m) to p) remain functionally unchanged. 20
类似技术:
公开号 | 公开日 | 专利标题
EP3304409B1|2019-08-07|Securing digital data
Erway et al.2015|Dynamic provable data possession
EP2446579B1|2020-12-09|Process for mutually authenticating a reader and a radio tag
EP2323306A1|2011-05-18|Secured data transmission method and encryption and decryption system enabling such a transmission
FR2789829A1|2000-08-18|METHOD FOR VERIFYING THE USE OF PUBLIC KEYS GENERATED BY AN ON-BOARD SYSTEM
EP2795833B1|2020-12-02|Authentication method between a reader and a radio tag
EP0346180B1|1993-02-24|Apparatus for protected data communication
FR2933216A1|2010-01-01|METHOD AND SYSTEM FOR VALIDATING A SUCCESSION OF EVENTS VECUTED BY A DEVICE
EP2494491B1|2017-07-12|Identification by means of checking a user's biometric data
WO2012152607A1|2012-11-15|Device and method for generating keys with enhanced security for fully homomorphic encryption algorithm
Ling et al.2014|InterCloud RAIDer: A do-it-yourself multi-cloud private data backup system
US20150023498A1|2015-01-22|Byzantine fault tolerance and threshold coin tossing
CA2867241A1|2013-09-19|Method for encrypting a plurality of data in a secure set
Reyes-Anastacio et al.2018|A data integrity verification service for cloud storage based on building blocks
EP3857810A1|2021-08-04|Cryptographic method of secure comparison of two secret data x and y
WO2009083528A1|2009-07-09|Method and system for generating stable biometric data
FR2916317A1|2008-11-21|PROTECTION OF EXECUTION OF A CRYPTOGRAPHIC CALCULATION
Ali et al.2019|Distributed File Sharing and Retrieval Model for Cloud Virtual Environment
WO2009083527A1|2009-07-09|Method and system for authenticating individuals on the basis of biometric data
US20210192076A1|2021-06-24|Private Information Retrieval with Sublinear Public-Key Operations
Basma et al.2017|Towards Overcoming Limitations of Current Integrity Schemes in the Cloud Environment
FR3020888A1|2015-11-13|ENCRYPTION OF A SECRET PROTECTION KEY PROTECTING AT LEAST ONE SENSITIVE ELEMENT OF AN APPLICATION
FR3107416A1|2021-08-20|EFFECTIVE RANDOM TOKENIZATION IN A DEMATERIALIZED ENVIRONMENT
CH716296A2|2020-12-15|A method of multiple signature of a transaction intended for a blockchain, subject to geolocation, by means of cryptographic keys distributed among the nodes of a peer-to-peer network.
CH716265A2|2020-12-15|Method of storing computer data on a network with proof of storage from a compute node equipped with a cryptographic enclave.
同族专利:
公开号 | 公开日
CA2988265A1|2016-12-15|
WO2016199034A1|2016-12-15|
US10614230B2|2020-04-07|
RS59533B1|2019-12-31|
EP3304409A1|2018-04-11|
US20180181765A1|2018-06-28|
ES2762905T3|2020-05-26|
DK3304409T3|2019-11-11|
EP3304409B1|2019-08-07|
FR3037174B1|2017-06-02|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题
US20100058476A1|2005-04-28|2010-03-04|Kazuyoshi Isoda|Electronic information retention method/system, electronic information split retention method/system, electronic information split restoration processing method/system, and programs for the same|
US7809138B2|1999-03-16|2010-10-05|Intertrust Technologies Corporation|Methods and apparatus for persistent control and protection of content|
US8868914B2|1999-07-02|2014-10-21|Steven W. Teppler|System and methods for distributing trusted time|US10573605B2|2016-12-13|2020-02-25|University Of Florida Research Foundation, Incorporated|Layout-driven method to assess vulnerability of ICs to microprobing attacks|
US10291594B2|2017-08-31|2019-05-14|Fmr Llc|Systems and methods for data encryption and decryption|
US11165777B2|2019-05-30|2021-11-02|Bank Of America Corporation|Controlling access to secure information resources using rotational datasets and dynamically configurable data containers|
US11138328B2|2019-05-30|2021-10-05|Bank Of America Corporation|Controlling access to secure information resources using rotational datasets and dynamically configurable data containers|
US11153315B2|2019-05-30|2021-10-19|Bank Of America Corporation|Controlling access to secure information resources using rotational datasets and dynamically configurable data containers|
法律状态:
2016-06-01| PLFP| Fee payment|Year of fee payment: 2 |
2016-12-09| PLSC| Search report ready|Effective date: 20161209 |
2017-06-03| PLFP| Fee payment|Year of fee payment: 3 |
2018-06-12| PLFP| Fee payment|Year of fee payment: 4 |
2020-08-11| PLFP| Fee payment|Year of fee payment: 6 |
2021-06-28| PLFP| Fee payment|Year of fee payment: 7 |
优先权:
申请号 | 申请日 | 专利标题
FR1501179A|FR3037174B1|2015-06-08|2015-06-08|SECURING DIGITAL DATA|FR1501179A| FR3037174B1|2015-06-08|2015-06-08|SECURING DIGITAL DATA|
ES16733205T| ES2762905T3|2015-06-08|2016-06-08|Digital data assurance|
PCT/IB2016/053357| WO2016199034A1|2015-06-08|2016-06-08|Digital data security|
RS20191432A| RS59533B1|2015-06-08|2016-06-08|Securing digital data|
DK16733205T| DK3304409T3|2015-06-08|2016-06-08|DIGITAL DATA SECURITY|
CA2988265A| CA2988265A1|2015-06-08|2016-06-08|Digital data security|
EP16733205.5A| EP3304409B1|2015-06-08|2016-06-08|Securing digital data|
US15/580,618| US10614230B2|2015-06-08|2016-06-08|Digital data security|
[返回顶部]